To create a virtual machine (VM), virtual machine software, such as Microsoft's Virtual Server, starts an instance of a virtual machine creator that creates the desired VM from multiple stored files. As shown in FIG. 1, the virtual machine creator 10 creates a first VM (VM1) using a VM configuration file (VM Config1) that includes information explaining the machine (system) configuration of the VM to be created and a virtual hard disk (VHD1) that stores a virtual disk image file representing a hard drive (disk) in a VM environment. In other words, the files VHD1 and VM Config1 together provide the information needed by VM creator 10 to create VM1. Similarly, the files VHD2 and VM Config2 together provide the information needed by VM creator 10 to create VM2. As illustrated in FIG. 1, a saved state of the memory contents of the VM may be used by VM creator 10 to relaunch VM2 so that VM2 starts at a preselected saved state. Conventional virtual machine applications, such as Virtual VPC 2004 and Virtual Server 2005 from Microsoft Corporation, allow users to save the running state of a virtual machine and restore it at a later point of time. The saved state file contains all the memory contents of a VM at the point it was saved as well as the state of all the devices that were running in the VM.
As illustrated in FIG. 1, a virtual machine application needs a minimum of two files to launch a virtual machine. They are the virtual disk image file (VHD) and the virtual machine configuration file (VM CONFIG). The virtual machine creator application 10 may read information from this file and construct a virtual machine. However, to move a VM from one physical machine to another, the user has to move both the VHD and VM CONFIG files. Moreover, there is no way an administrator can enforce that a particular VM configuration file is used with a particular disk image. As a result, a user can create a new VM and attach a disk image to it, even if it is from the wrong one. Also, if virtual machines are check-pointed, then there are multiple saved state files that represent the virtual machine at different points in time. Maintaining all these saved state files can be a tedious process and make migration of virtual machines cumbersome. An improved VM migration technique is desired.
Virtual machine hard disks (VHDs) are virtualized in the form of files that reside on the native host file system. Each virtual hard disk type has its own standard file format that varies by VHD type. There are several types of VHDs; the following types of VHD formats are supported by Microsoft Virtual PC and Virtual Server:                Fixed hard disk;        Dynamic hard disk;        Differencing hard disk;        
Unfortunately, as noted below, the file structures and file formats of conventional VHDs limit the uses of VHDs by the VM creator 10.
In particular, conventional VHD file formats provide a mechanism to layout the VM disk data in a file; however, conventional VHD file formats do not provide a mechanism to store information that provides more detail about what data is stored in the VHD and the characteristics of that data. Accordingly, to learn more about the stored VHD data from the disk image, the user has to attach the disk image to the VM, launch the VM using the VM creator 10, and then read the contents through the VM. This is an expensive and tedious operation.
To illustrate this, suppose a user needs the ability to find out if a VM has been patched or not. If it has been patched, the user would like to know to what level it has been patched and whether it is safe to start up the VM or not. This information is very valuable as the user would prefer to find out the patch information and make a decision if he/she wants to start a virtual machine. By checking the patch state, the user can potentially stop an un-patched VM from connecting to the network and create a vulnerable point on the network. Unfortunately, as just noted, the user conventionally has to start the VM to check the patch state. A solution is desired whereby the user may check the VHD data without starting the VM.
The conventional VHD file formats also do not provide any mechanism to store information that can help a policy engine to make decisions on whether a virtual disk image could be used by a particular hardware environment, or by a particular user. As a result, the conventional VHD file formats do not permit a user to create a virtual disk image and install operating systems and/or applications and to safely distribute the VM on the Internet. This is because any virtual machine product which understands the current file format will be able to use the operating system and application present in the virtual disk image. It is desired to provide a mechanism whereby a policy engine can decide if a particular user may or may not use the operating system/application present in a particular virtual disk image.
The conventional VHD file formats further do not provide a mechanism to store information that specifies the type of physical hardware on which the operating system inside the virtual hard disk image can run. This is desirable since a VM can typically move from one physical machine to another, provided that some of the hardware components (e.g. processors) are identical. This knowledge is crucial to enable a VM system to decide if it can move a live VM to another physical machine. It is thus desirable to provide a mechanism by which a policy engine can decide if a particular VM can move from one physical machine to another physical machine.
The conventional VHD file formats do not provide a robust mechanism to enforce a timeout policy that would allow an administrator to publish disk images which can be used only for a certain period, or only during a certain period of time in the day. It is desirable to provide a mechanism by which the policy engine may monitor if the virtual disk image has expired or is unusable at a particular time of day.
The conventional VHD file formats do not provide any mechanism to store DRM information. Without any DRM information, the virtual disk image cannot be used as a vehicle for software distribution. It is desired to provide sufficient DRM protections so as to enable a software vendor to create a virtual disk image with its application installed in it for distribution on the Internet to users, who would be able to download their license keys separately to use the virtual disk image.
The conventional VHD file formats do not provide any mechanism to control the usage of a virtual disk image in a particular network environment such that, for example, a system administrator may setup certain virtual machines so that they can run only in a secure network environment. It is desired to create a VM environment in which an illegal user cannot get access to the virtual disk images and launch a virtual machine from a virtual disk image in an environment different from the intended one.
As a convenience to VM users, it is also desirable for VM users to be able to quickly search a virtual disk image to determine its contents. Conventionally, given a large number of disk images, if a user has to find a particular disk image, he has to attach the virtual disk image to a virtual machine and start it up to find out if it contains what he is looking for. The other option is for the user to uniquely name the disk images or to store them in separate uniquely named folders that may be very tedious to setup and maintain. A better way to search virtual disk images is desired.
In addition, the conventional virtual disk image file format does not allow third party vendors to add custom information without modifying the file format. This restricts the extensibility of the format. For example, an anti-virus product might want to store some information that indicates whether a virtual machine disk image was checked for infection. Unfortunately, in the conventional implementation of the VHD there is no way to store this information in the file without modifying the file format. An extensible mechanism is desired that enables metadata to be stored in a virtual machine disk image.
In conventional virtual disk image file formats, there is also no mechanism for a user to store notes related to the modifications made to a virtual disk image. Such a mechanism is desired.